Redis Cluster是Redis官方提供的Redis集群功能。
为什么现需要Redis Cluster
- 主从复制不能满足高可用的要求
- 随着业务的发展，需要更高的QPS
- 数据量的增长导致服务器内存不足以存储
- 网络流量的增长，业务的流量已经超过了服务器的网卡的上限值，可以考虑使用分布式技术来进行分流。
- 离线计算，需要中间环节缓冲等别的需求。
数据分布
当单机的redis节点无法满足要求，按照分区规则把数据分到若干个子集中。
常见的数据分布方法
顺序分布
比如有1-100个数据，要保存的三个节点上，那么1-33号数据放在第一个节点上，34-66号数据放在第二个节点上，依此类推。
哈希分布
对键进行hash后，根据哈希码，来进行分区。
常见的分区方式有：
- 节点取余分区：对key进行hash之后，与节点数进行取余运算，根据余数不同保存在不同的节点上。该分区方式的问题就是不利于节点数量的调整。但节点数量变动时，大量的数据需要迁移。
- 一致性哈希分区：将所有的数据当作一个token环，token环中的数据范围时0到2的32次方，然后为每一个数据节点分配一个token范围值，这个节点就负责保存这个节点范围的数据。对每一个key进行hash运算，将哈希后的结果在哪个token范围内，则按照顺时针去找最近的节点，这个key就会被保存在这个节点上。
- 虚拟槽分区：虚拟槽分区时Redis Cluster采用的分区方式，预设虚拟槽，每个槽就相当于一个数字，有一定的范围。每个槽映射一个数据子集，一般比节点数大。Redis cluster中预设的虚拟槽的范围为0到16383
虚拟槽分区的步骤：
1 | 1.把16384槽按照节点数量进行平均分配，由节点进行管理 |
虚拟槽分区的特点：
使用服务器端话管理节点，槽，数据
可以对数据进行打散，又可以保证数据分布均匀。
Redis Cluster基本架构
节点
Redis Cluster是分布式架构，即Redis Cluster中有多个节点，每个节点购汇负责数据读写操作，每个节点之间会进行通信，
meet操作
节点之间会互相通信
meet操作时节点之间完成相互通信的基础，meet操作有一定的频率和规则。
分配槽
把16384个槽平均分配给节点进行管理，每个节点只能对自己负责的槽进行读写。由于每个节点之间都彼此通信，每个节点都知道另外节点负责管理的槽范围。
客户端访问任意任意节点时，对数据key按照CRC16规则进行hash运算，然后对运算结果对16383进行取余，如果余数在当前访问的节点管理的槽的范围内，则直接返回对应的数据，否则会告诉客户端去哪个节点获取数据，由客户端去正确的节点获取数据。
复制
保证高可用，每个主节点都有一个从节点，当主节点故障，cluster会按照规则实现主备的高可用
客户端路由
moved重定向
1 | 1. 每个节点通过通信都会共享redis cluster中槽和集群中对应节点的关系 |
ask重定向
对集群进行扩容和缩容时，需要对槽及槽中的数据进行迁移。
当客户端向某个节点发送命令，节点向客户端返回moved异常，告诉客户端数据对应的槽节点信息。如果此时正在进行集群拓展或者缩空操作，当客户端向正确的节点发送命令时，槽及槽中数据已经被迁移到被的节点了，就会返回ask。
步骤：
1 | 1. 客户端向目标节点发送命令，目标节点中的槽已经迁移到别的节点上，此时目标节点会返回ask转向给客户端 |
故障发现
Redis cluster通过pin/pong消息实现故障发现，不需要sentinel。
ping/pong不仅能传递节点与槽的对应消息，也能传递其它状态，比如：节点主从状态，节点故障等。
主观下线
主观下线只代表一个节点对另一个节点的判断，不代表所有节点的认知。
1 | 1. 节点1定期发送ping消息给节点2 |
客观下线
当半数以上持有槽的主节点都标记某节点主观下线时，可以保证判断的公平性。
客观下线流程：
1 | 1. 某个节点接收到其它节点发送的ping信息，如果接收到的ping消息中包含了其它pfail节点，这个节点会将主观下线消息添加到自身的故障列表中，故障列表中包含了当前节点接收到的每一个节点对其它节点的状态信息。 |
故障恢复
资格检查
1 | 对从节点的资格进行检查，只有难过检查的从节点才可以开始进行故障恢复 |
准备选举时间
使偏移量最大的从节点具备优先级成为主节点的条件。
选举投票
对选举出来的多个从节点进行投票，选出新的主节点
替换主节点
当前从节点取消复制变成离节点。执行cluster del slot撤销故障主节点负责的槽，并执行cluster add slot把这些槽分配给自己
向集群广播自己的pong消息，表明已经替换了故障从节点
v1.5.2